Microblog is a typical user generated content (UGC) service. Data generation is closely related to behaviors of a user. When data cannot be written to an underlying storage server because of an error or operation and maintenance issues, a user may conclude that there is an error in the background system.
To reduce the impact by an error of an underlying service on user experience, a common method is using flexible policies. For example, only some available data may be returned when the error occurs, or data of some duplicates may be used in reading data. In this scenario, generally, affected data is un-writable. Further, all write operations of the user may fail. To lower the impact of a factor such as a machine error on the user, a fast data recovery and operation and maintenance means is needed.
In the existing technology, redoing logs is a common way to recover data by a background service. For example, a log of a write action is first recorded locally or remotely, and when a machine has an error, the write action in the log can be replayed to recover data.
Redoing the log requires replay of the original write sequence number (Seq), to ensure the correct sequence of write actions. However, a recovery starting from Seq=0 generally costs a lot of time (equivalent to performing all write actions over). Therefore, besides the log redoing, a data snapshot technology may be further needed to export a snapshot of memory data to a magnetic disk and record a Seq of an export moment. Before a data recovery, the snapshot may be first loaded to memory. The log redoing may be continued from a Seq of the snapshot point, thereby reducing the time spent in redoing the log.
In a conventional solution, when a master device has an error in performing data migration, a data snapshot of a current day or a previous day needs to be acquired first. Then a log file is acquired from a master device (or a log is acquired remotely). Before the log is duplicated, it is required to inhibit writing to the master device, thereby ensuring data consistency in a migration process. If data is written to an old machine but a log is not duplicated to a new master device, loss of the data may be caused. Therefore, generally, in a data recovery process, operations such as snapshot duplication, master device write inhibition, log duplication, snapshot recovery, and log redoing need to be performed in sequence.
Because in the conventional solution, it is required to perform complex log redoing operations, writing to a master device may need to be inhibited for a long time, an un-writable time for the external user (that is, for a user) may be long. A user obviously can experience the error in the system operations.